Field-Level Encryption for FlatBuffers
AES-256 encryption with HD wallet key derivation, meeting federal data-at-rest requirements
Capabilities
Field-Level Encryption
Encrypt individual fields within FlatBuffer records. The binary structure stays intact so upstream code can read encrypted values without schema changes.
HD Wallet Key Derivation
Keys derived from BIP-39 seed phrases using HKDF-SHA256. Each field can have its own derived key for granular access control.
High Performance
Generate and encrypt 1 million records at 50+ MB/s using WebAssembly. Streaming export avoids memory accumulation.
Zero Server Dependency
All cryptographic operations run client-side in the browser. No data leaves your device unless you explicitly export it.
Cryptographic Implementation
Federal Compliance Standards
This implementation uses cryptographic algorithms approved for protecting federal data at rest:
CNSA 2.0
Commercial National Security Algorithm Suite 2.0 mandates AES-256 for all National Security Systems. Quantum-resistant algorithm support required by 2025.
View PDF →SP 800-111
Guide to Storage Encryption Technologies for End User Devices. Endorses AES-256 for data at rest with proper key management.
View Publication →140-3
Security Requirements for Cryptographic Modules. AES-256 is approved for all security levels (1-4) in federal cryptographic modules.
View Standard →STIGs
Security Technical Implementation Guides require FIPS 140-validated AES encryption for protecting CUI and classified information.
View STIG Library →wasm/openssl-fips/.
Use Cases
Defense & Intelligence
Field-level encryption for mission data with per-user key derivation and need-to-know access control.
Healthcare (HIPAA)
Encrypt PHI fields while leaving non-sensitive metadata readable for indexing and routing.
Financial Services
Protect PII and transaction data at rest with audit-ready key management from HD wallets.
Zero-Trust Architectures
Data remains encrypted until the authorized recipient decrypts with their derived key.
Public Key Infrastructure
Alice encrypts data with Bob's public key. Only Bob can decrypt with his private key.
Login to try the interactive encryption demo
LoginHow ECIES Encryption Works
Ephemeral Key Generation
Alice generates a one-time ephemeral key pair for each encryption. This provides forward secrecy - if Alice's main key is compromised, past messages remain secure.
ECDH Key Exchange
Alice uses her ephemeral private key and Bob's public key to compute a shared secret via Elliptic Curve Diffie-Hellman. Only Alice and Bob can derive this shared secret.
HKDF Key Derivation
The shared secret is passed through HKDF-SHA256 to derive a symmetric AES-256 key and nonce. This stretches the shared secret into cryptographically strong key material.
AES-256-CTR Encryption
Data is encrypted using AES-256 in CTR mode. CTR mode is a stream cipher that preserves plaintext length - critical for FlatBuffers where field sizes must remain constant.
Header Transmission
The ephemeral public key and nonce are sent as a header alongside the ciphertext. Bob uses this header plus his private key to derive the same symmetric key and decrypt.
Adversarial Security
Cryptographic keys derive blockchain addresses. Value at an address proves key integrity.
What is Adversarial Security?
A novel trust mechanism where cryptocurrency value acts as a security bond for cryptographic keys. The same public key used for encryption can derive addresses on blockchain networks. If significant value remains at those addresses without being drained, it provides strong evidence that the private key hasn't been compromised.
Key Derivation
Any cryptographic public key (secp256k1, Ed25519) can mathematically derive addresses on cryptocurrency networks like SUI and Monad. This is a one-way function — the address is uniquely tied to that key.
Value as Trust Signal
Anyone can send cryptocurrency to an address without permission. If you rely on a key being secure, you can deposit funds as a "security bond." The more value at stake, the higher the trust signal.
Adversarial Assumption
If a private key is compromised, a rational attacker drains the funds immediately. Undrained value = uncompromised key. Data signed by that key, or encrypted for it, can be trusted.
Real-Time Proof
Blockchain explorers show balances updated every block. This provides continuous, verifiable proof of key integrity — not a point-in-time certificate, but live security monitoring.
Trust Through Value
The flow below shows how a public key transforms into verifiable trust through blockchain-secured value.
Real-Time Verification
Chain monitoring shows whether funds remain per block — live proof of key security.
Permissionless Trust
Anyone can increase trust by sending funds to a key they rely on.
Adversarial Assumption
If key is compromised, rational attacker drains funds immediately.
Login to derive addresses from your keys and check live balances across multiple blockchain networks.
Field-Level Encryption
Generate FlatBuffer records and visualize individual field encryption using Alice/Bob keys
Schema Viewer
View FlatBuffers schema (.fbs) and equivalent JSON Schema
.fbs Schema
JSON Schema
Convert JSON ↔ FlatBuffer
JSON Input
Hex Input (FlatBuffer)
Streaming Dispatcher
Route mixed FlatBuffer messages to queues by type
How Streaming Works
Message Flow
FlatBuffers are self-describing binary messages with a 4-byte type identifier prefix. The streaming dispatcher reads this identifier and routes each message to the appropriate queue based on its type.
[TYPE_ID:4bytes][SIZE:4bytes][FLATBUFFER:N bytes]
Message Queues
Each message type has a dedicated queue with a fixed capacity. When full, oldest messages are overwritten (FIFO). This enables constant-memory streaming for high-throughput scenarios without allocations.
- O(1) insertion and removal
- Zero allocation after initialization
- Lock-free single-producer design
Use Cases
- Telemetry - Route sensor data by device type
- Gaming - Separate entity updates from events
- Finance - Dispatch orders, trades, and quotes
- IoT - Process heterogeneous device streams
API Reference
Wire Format
Each message is size-prefixed (little-endian) followed by a 4-byte file identifier for routing, then the FlatBuffer payload.
Initialization
Streaming Data
Access Patterns
Interactive Demo
Cryptographic Identity
Generate a vCard with your public keys for secure sharing
FlatBuffer Studio
Create schemas, generate code, and build FlatBuffers in the browser
Files
Schema Definition
Parsed Structure
Item Editor
Preview
// Schema preview will appear here...
Generated Files
Generated Code
// Generated code will appear here...
Data Entry
Buffer Output
Decoded JSON
Build or upload a buffer
WASM Compiler (flatc)
Run flatc in the browser or Node.js
Encryption Module (WASM)
AES-256, X25519, secp256k1, P-256, Ed25519
Aligned Binary Format
Zero-overhead, fixed-size structs from FlatBuffers schemas for WASM/native interop
Why Aligned Format?
Zero-Copy Access
TypedArray views directly into WASM linear memory. No deserialization overhead - just cast and access.
Fixed-Size Layout
Predictable memory layout with proper alignment. Perfect for arrays of structs in shared memory.
FlatBuffers Schema
Use familiar FlatBuffers .fbs syntax. Structs and tables with scalars and fixed-size arrays are supported.
Multi-Language Output
Generate C++ headers, TypeScript classes, and JavaScript modules from a single schema definition.
Code Generator
Paste a FlatBuffers schema below to generate aligned binary format code:
Schema (FBS)
Generated Code
// Generated code will appear here...
Supported Features
Supported
- Scalars: bool, byte, ubyte, short, ushort, int, uint, long, ulong, float, double
- Fixed-size arrays:
[float:3],[int:16] - Hex array sizes:
[ubyte:0x100](256 bytes) - Nested structs (inlined by value)
- Enums with explicit base type
- Fixed-length strings (set String Length > 0)
Not Supported
- Variable-length strings (without String Length)
- Variable-length vectors
- Unions
- Tables with optional fields (use structs)
Usage Example
// C++ - Direct struct access in WASM
#include "aligned_types.h"
void processEntities(Entity* entities, size_t count) {
for (size_t i = 0; i < count; i++) {
Entity& e = entities[i];
e.health -= 10;
e.position.x += e.velocity.x * dt;
// Zero overhead - direct memory access
}
}
// Export for JS binding
extern "C" void update_entities(Entity* ptr, int count) {
processEntities(ptr, count);
}
WASM Runtime Integration
Run the encryption module in any language with WebAssembly support
Why WASM Runtimes?
Single Auditable Implementation
One C++/Crypto++ codebase compiled to WASM. Audit once, deploy everywhere.
Battle-Tested Crypto
Crypto++ has 30+ years of production use in security-critical applications.
Cross-Language Interop
Data encrypted in Go can be decrypted in Python, Rust, Java, and vice versa.
Available Runtimes
Download pre-built bindings and template projects for your language:
Pure Go WebAssembly runtime - no CGo required
go get github.com/tetratelabs/wazero
Run WASM modules with wasmer-python or wasmtime
pip install wasmer wasmer-compiler-cranelift
Pure Java WASM interpreter - no JNI required
com.dylibso.chicory:runtime:1.5.3
Core WASM Module
Download the core encryption module for manual integration:
flatc-encryption.wasm
Core encryption module compiled from Crypto++ (~1.2MB)
encryption.mjs
JavaScript loader with TypeScript definitions